
\section{Troisième itération}
\subsection{Description}
La troisième itération du framework consiste à prendre en compte le lien a-un entre les classes PassagerStandard et Autobus.
Pour cela il a fallu tester puis compléter le code des deux classes PassagerStandard et Autobus.


\subsection{Réalisation des tests}
La substitution d'objet ou polymorphisme, consiste à remplacer une instance d'une classe par une instance d'une autre classe 
(qui doit représenter la même abstraction que la classe qu'elle remplace). 
Cette substitution, qui permet le remplacement d'un morceau de code par un autre, doit se faire de manière à minimiser l'impact sur le reste du code.

Comme les classes PassagerStandard et Autobus sont codées indépendamment l'une de l'autre et qu'il faut gérer le lien a-un entre ces deux classes,
il a fallut créer des classes faussaires (FauxBus et FauxPassager) pour pouvoir réaliser les tests (mock object). 
Chacune de ces classes doit pouvoir implémenter les mêmes comportements que sa classe homologue.\\
Chacune des classes faussaires s'articule autour d'une variable $status$ vallant une des constantes définissant l'état de l'objet. 
Cette variable $status$ n'est modifiable que par les tests. De plus chacune de ces deux classes faussaires contient les même méthodes 
que leurs homologues. Pour pouvoir assurer ce dernier point, une interface \verb+Bus+ et \verb+Passager+ a été créée. 
Ainsi les classes FauxPassager et PassagerStandard héritent de Passager et les classes FauxBus et Autobus héritent de Bus. 
Un diagramme de classe a été réalisé résumant les choix d'implémentations. (cf. \ref{diagramme de classe})

\begin{figure}[h]
\centering
\includegraphics[scale=1.2, angle=90, height=20cm]{diagrammeClasse.png}
\caption{Diagramme de classe}
\label{diagramme de classe}
\end{figure}
\subsection{Sources}

Au niveau de la classe Autobus, la gestion de la suppression d'un passager se fait dans la méthode \verb+demanderSortie+.
Nous effectuons une recherche du passager à supprimer dans le tableau \verb+ + à partir du champ "nom" du passager qui sert dans ce cas d'école
d'identifiant pour passager. Cette recherche s'effectue au moyen d'une comparaison de chaînes de caractère des champs nom du passager avec 
ceux contenus par bus en invoquant la méthode \textbf{Equals} qui teste le cas d'égalité d'état. 
Une fois trouvé, on échange le dernier passager avec celui à supprimer. 
L'ajout d'un passager se fait en fin du tableau. Pour réduire la complexité en temps, 
nous avons décidé d'ajouter un champs privé \verb+nbPassager+ qui évite le parcours à chaque appel du tableau. 
Ainsi, l'ajout se fera en temps constant.
\textbf{A VERIFIER !}
Ceci a été possible grâce au fait que la substitution d'un objet par un autre peut se faire s'il le remplaçant est un sous type de l'objet 
qu'il substitue.
par exemple, pour la méthode monterDans(Bus); qui prend en paramètre un bus, Vu que fauxBus est un sous-type de bus, l'utulisation de cette méthode
avec la classe faussaire de bus est possible.
\textbf{A VERIFIER !}


	
\section*{Deuxième Itération : le paquetage tec}	
Dans cette partie, nous allons nous préoccuper de la manière de fournir 
l’ensemble des classes développées à un client. C’est à dire définir un paquetage et le masquage d’information adéquate.

Ce travail s’effectue toujours en parallèle. Chaque tandem va inclure les classes qu’il a développées dans ce paquetage.
Chaque tandem crée à partir de son répertoire de travail :
\begin{itemize}
\item un répertoire src pour vos fichiers sources ;
\item un répertoire build pour les fichiers compilés.   
\end{itemize}
Tous les fichiers appartenant au même paquetage doivent être placés dans le même répertoire car lors de l'importation des paquetages 
l'instruction \textbf{import}, chargée de l'importer, prend en compte un chemin d'accès au fichier contenant les paquetages. L'instruction 
\textbf{package} en entête de nos sources du paquetage permet de créer le répertoire racine du paquetage lors de la compilation.
Par exemple ici : import tec/*; du fichier Main.java signifie qu'il faut importer toutes les classes situées dans le répertoire tec.\\
  				  package tec; permet de placer le fichier compilé dans le dossier tec (et de le créer si il n'existe pas).\\
				  
Afin que les fichiers $.java$ puissent communiquer entre eux, ils faut qu'ils connaissent l'arborescence des autres fichiers. 
Pour cela, pour tous les fichiers contenus dans le paquetage tec, il faut rajouter \textsf{package tec} avant tout autre ligne de code. 
Ainsi, à l'éxécution, le chemin vers chaque classe sera connu.\\

Les classes accessibles en dehors du paquetage sont celles qui ont une portée publique, c'est à dire les classes \textbf{Autobus} et 
\textbf{PassagerStandard}.\\ 

Lors de l'execution de la commande \textsf{javac -d build -sourcepath src src/tec/LancerTests.java} l'option -d nous permet de 
définir le répertoire de destination dans lesquel seront placés les fichiers compilés (.class) et l'option -sourcepath donne 
le chemin vers le répertoire racine de tous les fichiers sources $.java$. Etant donné que LancerTests.java est dans le paquetage tec, 
lors de sa compilation, tous les autres fichiers du même paquetage sont compilés aussi dans un fichier tec placé dans le répertoire de 
destination (build/tec).\\


Afin de lancer l’exécution des tests unitaires de la classe LancerTests à partir du répertoire du projet.
La commande de compilation \textsf{javac -d build -sourcepath src src/tec/LancerTests.java} permet de compiler LancerTests.java 
ainsi que toutes ses dépendances situées dans les répertoires src et src/tec/LancerTests.java. Alors que la commande 
\textsf{javac -d build src/tec/*.java} se chargera simplement de compiler l'ensemble des fichiers sources présent dans le dossier tec.\\

Il faut executer la commande \textsf{java -classpath build -ea tec/LancerTests}. 
L'option \textit{-classpath} donne le chemin vers tous les fichiers .class, qui se trouvent donc dans le répertoire build, 
où sont stockés les fichiers .class du paquetage tec. La seconde option -ea permet d'activer les assert présents dans les tests. 
Et enfin on spécifie le fichier "main" que l'on veut executer, c'est à dire LancerTests.\\

Chaque tandem archive son répertoire tec/*.class et non dans build/tec/*.class dans un fichier archive «jar » nommé bus.jar ou passager.jar.
La classe LancerTests appartient au paquetage tec, qui lui n'appartient au package build. 
Or la syntaxe build/tec/*.class spécifie qu'il y aurait une architecture de package à partir de build. 
Build n'est en fait qu'un répertoire de notre dépot, où les fichiers .class sont stockés, et non pas un package.\\

  
\section*{Remarques}	
	
	Par la lecture de simple.java de la recette, on remarque que le client a accès aux classes \textbf{Autobus} et \textbf{PassagerStandard} 
	et aux interfaces \textbf{Bus} et \textbf{Passager}. Toutes les autres classes doivent rester inaccessibles, car elles concernent 
	la structure même des algorithmes qui sont gérés par les classes ci-dessus.
	De plus, l'utilisateur n'a pas accès au tests car les classes qu'il utilise sont censés déja être testées et validées.

\section*{Synthèse}

  Les deux itérations ont été réalisées grâce au découpage en deux équipes qui permet d'avancer plus rapidement 
  tout en évitant un maximum d'erreurs. Vu l'ampleur que prend notre code à chaque séance, nous avons commencé d'un commun accord à commenté notre 
  code toujours, pour fournir un documentation et faciliter la tâche à chauqe tandem.
  L'introduction d'abstraction grâce aux interfaces nous permet donc d'envisager pour la suite la création de nouveaux types 
  de passagers ou même de bus plus représentattif de la réalité.

\end{document}

